The client/server world of computing is emerging as an attractive and viable way for large corporations to avoid the limitations existing in mainframe computer applications. A client/server software application environment is one in which a software application program may access and manipulate data from a distributed system (server) or a stand-alone workstation (client). This differs from mainframe operations that require all applications to run directly on the mainframe computer and access data on that mainframe computer.
Many manufacturing processes such as automating manufacturing operations, communicating and displaying documents, and analyzing processes and other information may be more efficiently and profitably performed in a client/server application environment than in a direct mainframe environment. Various information management systems operations may also be more effectively performed in the client/server area. Furthermore, executive information systems of marketing, financial management and general management operations as well as employee data analysis systems can be better performed, in many instances, as client/server application programs than as direct mainframe computing operations.
For large corporations and other large enterprises, however, certain limitations exist in making client/server applications practical. For example, problems exist that prevent clients in large enterprises from locating and directing data to a single location so that a client or server may apply logic or processes on the data in a convenient manner. In these business environments, much of the necessary data is in mainframe computer databases or on various other systems. To take advantage of the flexibility of the client/server desktop applications for client/server computing, there is a need for software tools that allow easy access to the data. A major difficulty exists, however, in that the data that a client or server may need comes from many different sources.
Some software tools attempt provide a client/server data collection component to the desktop application. These attempts, for example, use a fourth generation language that embeds the data collection, the user interface, and component logic in one software tool. As a result, little actual isolation of the data collection component occurs. Isolating the data collection component is necessary, however, to permit a client to build at his desktop the desired application program.
Without any form of effective isolation, there is no way to efficiently change client/server data without also having to change client/server desktop application. In a large corporation, there maybe hundreds or thousands of client/server applications that need to be changed. In such a scenario, changes to the applications may significantly restrict the operation of a manufacturing plant or other facility that uses the data in the database.
Thus, there is a need for a method and system that isolates the client/server desktop application from the data that may exist in a mainframe database or elsewhere.
There is a need for a method and system that permits isolating the data from the logic components in a database, thereby permitting the data to be used for many applications, while at the time permitting the applications to change without affecting the data.
Another limitation that exists in known client/server desktop applications arises due to logic components that are embedded in the data. Known systems require persons writing the user interface for the application to understand the definitions and locations of the data. The person writing the user interface for the desktop application, however, usually is not the person that best understands the data definitions or the structure of the database. This unnecessarily complicates the process of creating client/server desktop applications and limits the ability for these applications to be fully usable by the client.
Therefore, there is a need for a method and system that removes the burden of defining and locating the data from the client that creates the user interface for the desktop application and that places that burden on the person that constructs the database.
In a large corporation, yet another problem occurs without isolation between the data components and the other components of the particular client/server application. The problem is that with known client/server applications a large corporation must take all data (which may in various or different forms and at different locations) and place the data in a common database so that the various client/server applications may access the data. What results in this situation, however, is that corporations place a tremendous amount of redundant data in a common database to permit the client/server application to access the data. This evolution often takes a large amount of effort on the part of the corporation or enterprise. Additionally, in translating the data from its native form to a common database, numerous occasions for error may occur.
As a result, there is a need for a method and system that permits accessing data elements or data points in there native form without having to translate or input data in a common database for client/server applications.